Release 10.1A: OpenEdge Getting Started:
Database Essentials

Testing your recovery strategy

The only valid backup is your last tested backup. This underscores the need to test your backup strategy on a regular basis. This does not mean that you should delete your production database and restore from backup to see if it works. It is best if you can restore your database to a different location on disk, or better yet to a different system.

How often should you test your backup? If you are using an operating system utility to back up your database, it is a good idea to test your backup any time you modify the structure of your database. Since PROBKUP is database-aware you might not need to test for structure changes. However, it is still wise to test at least twice a year.

You must test the backup and the process when there are changes in staff or when the administrator might be out of town. Any member of the IT staff should be able to perform a well-documented recovery process. If you do not have an IT staff, you must ensure that each person who might be required to restore the system can follow the documented recovery procedures.

Your recovery procedures should be scenario-based. Common recovery scenarios, such as a loss of a disk (database, after-image, or application files, for example), fire, flood, and so on, must be clearly documented with step-by-step instructions to describe how to determine the root cause of the problem and how to recover from the event.

You hope you will never need to use your recovery plan. However, if the plan is well documented and the users were involved in calculating the cost/benefit trade-off in the beginning, then you will never be second-guessed or lose the trust of your user base because of a disaster.